build: update dependencies to latest versions - #2387

Both are new majors since the last actions bump (#2377). Verified no
workflow uses pull_request_target/workflow_run (affected by
checkout v7's fork-checkout change) or setup-python's removed
pip-install input, so no other changes are needed.

scripts/update_docs_versions.py enforces this in CI; the wear bump
to 1.4.0 left the inline comment stale.

Ran ./gradlew wrapper --gradle-version=9.7.0 instead of hand-editing
gradle-wrapper.properties, since that also refreshes
gradle-wrapper.jar and the gradlew/gradlew.bat scripts (and picks up
new 9.x wrapper properties like retries/retryBackOffMs). Drops the
distributionSha256Sum pin as requested.

AGP 9 provides Kotlin support natively and refuses to configure a
module that still applies org.jetbrains.kotlin.android alongside it.
Removes that plugin (all its declaration styles: catalog alias,
kotlin("android"), and hardcoded id(...)) from every module actually
wired into settings.gradle.kts, and drops the now-unused kotlin-android
catalog entry.

Also fixes two things AGP 9 surfaced as hard errors during
configuration, unrelated to the plugin removal itself:
- ApiDemos:java-app had a vestigial buildFeatures.compose = true with
  no Kotlin sources or Compose dependencies; AGP 9 now requires the
  Compose Compiler plugin whenever compose is enabled, so the dead
  flag is removed instead.
- tutorials/kotlin/Polygons used the now-unsupported
  proguard-android.txt default file, replaced with
  proguard-android-optimize.txt.

Standalone tutorial/sample directories not wired into
settings.gradle.kts (app-rx, the java/ and duplicate kotlin/ tutorial
folders) are untouched since they aren't part of the actual build
graph or CI.

androidx.core:core-ktx 1.19.0 requires compiling against API 37+;
CI's checkDebugAarMetadata caught this. Also switches
app-utils-ktx off its hardcoded compileSdk/targetSdk = 36 onto the
catalog value, matching every other module.

The org's zizmor policy check (triggered whenever workflow files
change) requires every `uses:` reference to be pinned to a full
commit SHA rather than a floating version tag. Touching these three
files for the checkout/setup-python bump made the check actually
run for the first time in a while and it flagged all 36 `uses:`
lines in them (not just the ones changed), so pins every action
reference across build.yml, lint.yml, and generate-v3.yml, each with
a version comment. release-please.yml is untouched by this PR and
wasn't flagged, so left as-is.

…stence

zizmor flagged two more findings once these files started being
scanned: excessive-permissions (Medium, blocking) because none of
the three workflows declared an explicit permissions: block and so
ran with the default broad GITHUB_TOKEN scope, and artipacked (Low,
informational) because checkout steps left credentials persisted in
the git config, which get exposed to anything that later reads the
workspace (e.g. artifact uploads).

- build.yml: contents: read (checkout + build only, no writes)
- lint.yml: contents: read, security-events: write (needed for
  github/codeql-action/upload-sarif)
- generate-v3.yml: contents: read (the actual PR push uses its own
  SYNCED_GITHUB_TOKEN_REPO secret via peter-evans/create-pull-request,
  not the default token)
- persist-credentials: false added to every actions/checkout step
  across all three files; none of them do a subsequent git push with
  the default token, so this is safe.

applyInsets(container: View) takes a non-null View, but every
kotlin-app activity called it as
applyInsets(findViewById<View?>(R.id.map_container)). Kotlin's
newer compiler no longer treats an explicit nullable type argument
on a platform-typed Java generic method leniently, so this now hard
fails to compile instead of silently working. All 24 call sites
always assumed a non-null result anyway (no null check), so this
just drops the incorrect nullable type argument.

The android-maps-utils bump (3.19.0 -> 5.1.1, part of the dependency
update) rewrote the library in Kotlin, which is a source-incompatible
change for these snippets:

- ClusterItem is now a Kotlin interface with val properties
  (position, title, snippet, zIndex: Float?), not Java-style getter
  methods. Clustering.kt and Multilayer.kt's MyItem implementations
  used `override fun getPosition()` etc., which no longer overrides
  anything Kotlin recognizes; converted to `override val` properties
  matching the new interface, constructor-promoted where possible.
- KmlLayer/KmlContainer expose getContainers()/getPlacemarks() as
  plain functions, not Kotlin properties, and KmlContainer's backing
  fields are now private. Feature.getId() is likewise a function.
  KML.kt used property-access syntax (layer.containers, feature.id)
  for all of these; switched to explicit method calls.
- GeoJsonLayer's default style accessor is getDefaultPointStyle(),
  not a defaultPointStyle property; fixed in GeoJSON.kt.
- KmlLayer/GeoJsonLayer constructors now take non-null
  Context/InputStream/JSONObject instead of the old nullable
  platform types. These snippet files use throwaway `= null`
  placeholders for doc purposes (never actually run), so added `!!`
  at each call site to match, consistent with the existing `map!!`
  pattern already used nearby.

Verified each API shape against the actual v5.1.1 source on
googlemaps/android-maps-utils (the library moved to a Kotlin
rewrite there) rather than guessing.

Two more spots the compiler hadn't reached yet in the previous fix pass:

- GeoJsonPointStyle (Kotlin, android-maps-utils 5.1.1) exposes
  isDraggable()/setDraggable(), getTitle()/setTitle(),
  getSnippet()/setSnippet() as plain functions, not var properties,
  so app-utils-ktx/GeoJSON.kt's `pointStyle.isDraggable = true` style
  assignments don't compile; switched to explicit setter calls.
- KmlContainer.getProperty() now returns String? (nullable); KML.kt
  passed it straight to Log.i's non-null second parameter, added !!
  (guarded by the existing hasProperty() check just above it).
- The JSONObject-argument GeoJsonLayer constructor is now annotated
  @throws(JSONException::class) in Kotlin, which surfaces in Java as
  a checked exception. snippets/app-utils (Java)'s
  addGeoJsonLayerJsonObject() didn't declare it; added `throws
  JSONException` to match its sibling method's existing pattern.

AGP 9's bundled lint now flags UnrememberedMutableState as an error
(previously warning/unreported): MarkerState(...) was created fresh
every recomposition, which would also reset marker drag state.
Wraps it in remember(markerData.id) so each marker's state survives
recomposition and is invalidated by React iOnly when the marker's
identity actually changes.